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RESOURCE RESERVATION IN 3G OR FUTURE GENERATION 
TELECOMMUNICATION NETWORK (TV) 

5 This invention relates to telecommunications networks operating the Internet 

Protocol (IP), and relates especially to a method of reserving resources. 

In third generation (3G) telecommunications networks, such as Universal 
Mobile Telecommunication System (UMTS), broad bandwidth is provided for services 
such as data and multimedia in addition to voice. An obvious need is that required 
1 0 Quality of Service (QoS) should be provided to users, but in IP networks, if contention 
for resources is not resolved, then QoS cannot be guaranteed. 

In IP networks or the Internet in general, Resource reSerVation Protocol 
(RSVP) is used to allow the network to reserve resources so as to provide QoS. RSVP 
can be used for QoS control locally or it may be used across IP networks. 
1 5 RSVP is an end-to-end protocol and is illustrated in Figure 1 . A transmitting 

user 10 sends to a receiving user 12 a message PATH. The PATH message carries the 
traffic characteristics information such as Tspecs to indicate the traffic behavior that is 
to be sent from the user 10. When the receiving user receives the PATH message, it 
sends a RESV message which contains QoS requests such as FlowSpecs. In practice, 
20 the transmitting and receiving users 10, 12 can be located remotely so that PATH and 
RESV messages pass through several nodes in UMTS. As each node receives either of 
the messages, it makes a decision as to whether adequate resources in that node can be 
reserved. If this is possible, then the messages are relayed to the next hop for the 
PATH message and to the previous hop for the RESV message. When the RESV 
25 message reaches the transmitting user 1 0, it begins to transmit data. 

Periodic refresh messages are sent subsequently to maintain the QoS status at 
each node in which it has been set up. — 

At the TSG-SA Working Group 2 meeting no. 12 in Tokyo, 6-9 March 2000 a 
disclosure was made by applicant of arrangements in which a mobile system using 
30 RSVP can communicate across a GPRS/UMTS network with another RSVP user; a 
proxy activated by the mobile receives and processes PATH messages and generates 
RESV messages in return. 

Applicant's copending European patent application no. [Lucent Case 

X. Chen 13 




Name/No X Chen 11/ IDS No. 122413] filed on even date describes an invenuve 
method in which RSVP messes are filtered at a mobile and at a Serving GPRS 
Support Node (SGSN) or a Gateway GPRS Support Node (GGSN), and the mobile 
and the support node are arranged to activate Packet Data Protocol (POP) Context 
5 Activation Procedure. However, conflicts can arise in certain circumstances. 

It is an object of the invention to provide a method of resemng 
resources in third or future generations of wireless mobi.e networks such as UMTS 
which has no or minimal impact on existing architecture or QoS procedures, that 
overcomes the aforementioned conflict. 

According to the invention, in a third or furore generation telecommunicate 
network, a method of allocating resources for user traffic passing between a mobue 
terminal and a remote user, characterized in mat unidirectional Resource reSerVafon 
Protocol (RSVP) messages arecompared so as to detect any previous RSVP message 
for that session. 

Preferably a flag is arranged to indicate that an RSVP message for mat sesston 

has already been sent „mm n,» 

In the accompanying drawings, Figure 1 illustrates the operahon of RSVP. The 
invention will be described by way of example only, with reference to figures 2-5 m 

20 Whl ° h: Figure 2 illustrates schematically the UMTS QoS architecture for the control 

plane; 

Figure 3 illustrates the interchange of messages in an uplink; 

Figure 4 illustrates the interchange of messages in a downlink; 

Figure 5 illustrates the uplink interchange of messages in an end-to-end 

25 session; and_ " 

Figure 6 illustrates the interchange of messages in a downlmk drrecuon. 
In Figure 2 the UMTS 20 comprises a Core Network (CN) 22 formed by a 
Gateway GPRS Support Node (GGSN) 24 and a Serving GPRS Support Node (SGSN) 
26- there is also a UMTS Terrestrial Radio Access Network (UTRAN) 28. A MT 30 
30 communicates with the UTRAN 28 across a radio interface. The MT 30 is connected 
to Termina. Equipment (TE) 32 which may run non-UMTS specific apphcation, The 

X. Chen 1 3 
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MT 30 is UMTS specific, and is capable of processing the traffic from the TE 32 to 
channel it appropriately to the UMTS, usually to the radio access network. 
The GGSN 24 communicates with an External Network 40. 
The UMTS 20 operates the application-specific Packet Data Protocol (PDP) 
5 context as usual to negotiate the QoS and activate the QoS control between the MT 30 
and UMTS network 20. 

Figure 3 illustrates traffic QoS in the uplink direction. RSVP messages are 
terminated only at the MT 30. The RSVP processing entity in the MT 30 is triggered 
by a PATH message from TE 32. In response, the MT 30 filters the message, analyses 

1 0 the RSVP parameters carried in the PATH message, and takes a decision whether to 
modify an existing secondary PDP context or to create a new secondary PDP context, 
to provide an updated QoS status. The secondary PDP context is then create/modified 
using the existing PDP Context Control procedures. If the PATH message is a first- 
time PATH message, a new secondary PDP context is created. If the PATH message is 

15 a refresh message with no modified QoS parameter, then no action is taken. The 
activate secondary PDP context message is sent by the MT 30 across the UTRAN 28 
to the SGSN 26, which generates a create/modify PDP context Request message and 
passes it to the GGSN 24. Return messages from the GGSN are processed similarly by 
the SGSN, and the MT 30 filters the message and passes a RESV message to the TE 

20 32. The TE 32 may send a refresh PATH message and receive a refresh RESV 
message. 

An important feature of RSVP is its uni-directional QoS request 
delivery. Specifically, the QoS status in the uplink direction set up by using RSVP 
does not apply to the QoS status in the downlink direction. This means that a QoS 

25 status that applies in both uplink and downlink requires two separate RSVP session 
set-up processes so as to be in line with the two way QoS status as contained by the 
PDP context of UMTS. This increases the QoS session set-up time and further 
complicates the QoS control and management in separate directions, because each 
direction needs to be controlled and maintained separately. 

30 However, there is a problem which may be termed a tc racing" problem because 

an RSVP terminal may not be UMTS aware, i.e. it may not be aware of a two-way 

3 X. Chen 1 3 
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nature of UMTS secondary PDP context. Then each end of an RSVP session may 
send RSVP messages independently from its remote peer. This means that the GGSN 
24 will receive two PATH/RESV messages, each of which applies for each direction 
(one for uplink and the other for downlink). The same "racing " problem occurs when 

5 the RSVP messages are terminated only at the MT 30. 

This racing problem has not previously been recognized. In the present 
invention the problem is resolved by checking if there is any existing secondary PDP 
context associated with RSVP QoS status by matching the end point information 
contained in the PDP context in comparison with the incoming RSVP messages. If no 

1 o match is found, then no action will be taken upon receiving an RSVP message which 
will then be transparently delivered to the remote peer end as before. 

In Figure 3 the points at which such message comparison takes place, in the 

MT 30, are indicated at M. 

In Figure 4, which illustrates a downlink, RSVP is terminated only at the MT 
1 5 30. The session is initiated from the External Network 40 and message processing is 
similar to that in Figure 3. The message comparison points, which may be in the MT 
30 or the GGSN 24, are also indicated at M . 

Figure 5 illustrates a variation in which a RSVP session is used end-to-end and 
is terminated at the MT 30 and the GGSN 24. The assumption is that TE 32 intends to 
20 set up an RSVP session with its remote peer, which also uses RSVP signaling, in the 
External Network 40. The Figure shows RSVP activated QoS in the uplink direction. 
When the MT 30 received a PATH message from TW 32, it checks to see if a PDP 
context exists for this RSVP session. If it does, the MT 30 triggers the Modify PDP 
context message if there is a change in QoS parameters. 
25 When the PATH message is received at the GGSN 24, it uses this information, 

again along with relevant local configuration, to see if QoS Negotiated is the same as 
QoS Requested. The PATH message is then sent to the external network. Radio 
Access Barrier (RAB) negotiation can take place between the SGSN 24 and the 
UTRAN ^8 if QoS Negotiated is different from QoS Requested. Finally, the RESV 
30 message returned from the external network is filtered by the GGSN, which creates or 
modifies a PDP Context request message, which is sent to the MT30. 



X. Chen 13 



I Printed:21 -03-2001 



The message comparison points in the MT30 and the SGSN24 are again 
indicated at M. 

Figure 6 shows the end-to-end situation for the QoS control in the downlink 
direction with filtering in the MT and GGSN. 
5 As before, the message comparison points to prevent the racing problem are 

indicated at M. 

To overcome the racing problem, the comparisons at the point M can be made, 
for example, in two ways, both involving use of a flag. 

In a first arrangement, a flag is made available in every PATH and RESV 
1 0 message by addition of a flag bit. 

For an MT-only terminated arrangement, for every session, the flag is set by 
the MT 30 the first time a RSVP message is sent or received by the MT 30. The flag is 
sent to the receiving end in the RSVP message for this session, and the receiving end 
recognizes that it does not need to send a return RSVP message for this session. The 
1 5 message in which the flag is set may be either a PATH message or a RESV message. 

If the flag has not been set, then no RSVP message has been sent and there can 
be no racing problem. 

For an MT and support node terminated arrangement, either the MT or ghe 
SGSN/GGSN can set the flag. In this arrangement, the MT 30, the GGSN 24 and the 
20 SSGN 26 need a small modification so that it/they can set the flag bit and recognize 
when the bit has been set in a received message, and to act (or not act) appropriately. 

In a second arrangement, a session flag is made available in PDP Context, 
which carries all the information about a session. The session flag can be set by 
either the MT 30 or the GGSN 24 or the SGSN 26. 
25 For example, when the GGSN 24 receives a first RSVP message (whether it is 

a Path or a RESV message) it sets the session flag in PDP context; the RSVP message 
is sent by the GGSN in a first direction to the remote end; it is to be understood that 
the remote end does not receive a flag. When a return RSVP message in the opposite 
direction is received by the GGSN 24, it checks if the flag is set for that session; if the 
30 flag is set, the GGSN discards any further RSVP messages for that session, therefore 
the racing problem is avoided. 
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The GGSN also checks to see if the QoS requirement is the same as in the PDP 
Context sent out; if the QoS requirement is higher, the GGSN actions the Modify 

Existing PDP context protocol. 

Usually a customer will have the option of deciding whether to change the QoS 

5 if it is lower than the present QoS requirement. 

In the first arrangement according to the invention with a flag in the RSVP 
message, the MT 30 prevents the racing problem and the remote end does not pass on 
the RSVP message. The first arrangement can be applied to messages as shown in Figs 
3 and 4 in which RSVP messages are filtered in the MT 30 only. 

In the second arrangement according to the invention with the flag in the PDP 
context, the GGSN prevents the racing problem and the remote end does not pass on 
the RSVP message. The second type of flag is applicable to messages as shown in 
Figures 5 and 6 in which the RSVP messages are filtered at the MT 30 and the GGSN 
24. 

! 5 By such comparisons at any of the indicated positions, the aforesaid "racing- 

problem is overcome. 

Either a RSVP message can be intercepted in the MT and the SGSN or GGSN 
26, the MT or support node then initiating PDP context activation procedure, as 
described in applicant's copending European patent application no. [Lucent Case 

20 Name/No. X. Chen 11/ IDS No. 122413] filed on even date, or the RSVP messages 
can be "piggybacked" in an IP packet , as set out in applicant's application no. 
00301782.9 filed on 3 March 2000. 



6 



X. Chen 13 



CLAIMS 



1 In a third or future generation telecommunication network, a method of 
allocating resources for user traffic passing between a mobile terminal (30) and 
a remote user characterized in that unidirectional Resource reSerVation 
Protocol (RSVP) messages are compared so as to detect any previous RSVP 
message for that session. 

2 A method according to Claim 1 in which a flag is arranged to indicate that 
a RSVP message for that session has already been sent. 

3 A method according to Claim 2 in which the flag is provided as an 
additional bit in every RSVP message. 

4 A method according to Claim 2 or Claim 3 in which the mobile terminal 
(30) is arranged to set the flag. 

5 A method according to Claim in 4 in which the mobile terminal (30) is 
also arranged to sense the presence of the flag. 

6 A method according to Claim 1 in which the flag is a session flag and is 
provided in Packet Data Protocol (PDP) context. 

7 A method according to Claim 6 in which a support node (24) of the 
network is arranged to set the flag and to send PDP protocol in a first direction. 

8 A method according to Claim 7 in which the support node(24) is also 
arranged to sense the presence of the flag in PDP Protocol received in a second 
direction and to discard any subsequent RSVP messages for that session. 

9 A method according to Claim 8 in which the support node (24) is also 
arranged to determine whether a Quality of Service requirement in the PDP 
message is higher than the Quality of Service requirement currently applicable 
to the session, and if so to modify the existing PDP message. 
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In the UMTS, resource reservation is provided by using unidirectional RSVP 
messages to set up a bi-directional PDP context. The MT 30 and a support node 24 can 
be arranged to compare incoming RSVP messages with any existing secondary PDP 
context, and if a match is found, no action is taken on the incoming message. The 
10 match is made by determining whether a flag is set. This eliminates "racing" when 
each end of an RSVP session sends an RSVP message. 



Figure 3. 
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